REMARKS 

The Applicant has received and reviewed the Official Action mailed by the 
Office on April 1 , 2008 (the "'Office Action"). The Applicant graciously appreciates 
the Office's attention to the instant application and submits this paper as a fully- 
responsive reply to the Office Action. The Applicant requests favorable 
consideration of this response and pending claims 1-15 at the earliest convenience of 
the Office. 

Rejection of Claims 1-15 under 35 USC §103(a) 

Claims 1-15 were rejected under 35 U.S.C. 103(a) as being unpatentable 
over US Pat No. 6,665,729 to Walker ("Walker") in view of US Pub. No. 
20040001514 Al to Wookey et al. ("Wookey"). The Applicant respectfully 
traverses this rejection. 

Applicable Legal Standard for Establishing a Prima Facie Case of 
Obviousness 

In KSR Intn'l Co.! v. Teleflex, Inc. (KSR), 550 U.S. , 82 USPQ2d 1385 

(2007), the U.S. Supreme Court reiterated that the appropriate framework for 
conducting the objective analysis required to make a determination of obviousness 
under 35 U.S.C. § 103 is provided in Graham v. John Deere Co., 383 U.S. 1, 148 
USPQ 459 (1966). Obviousness is a question of law based on underlying factual 



inquiries. (MPEP 2141 II.) As specified in Graham, a proper obviousness 
analysis is based on factual inquiries, which, in part, require that: 1 ) the scope and 
content of the prior art are to be determined; 2) differences between the prior art 
and the claims at issue are to be ascertained; and 3) the level of ordinary skill in 
the pertinent art is to be resolved. (Id. (citing Graham, at 17-18, 148 USPQ at 
467)). 

Applicant's Response 

Claims 1-10 

Claim 1 recites: 

A computer-implemented process comprising: 

determining a size of a data structure; 

selecting a data streaming protocol when the size exceeds a 
predetermined limit; 

selecting a buffered data protocol otherwise; 

sending data of the data structure consistent with the selected 
protocol. 

Walker is directed to a modified stream-based protocol implementation to 
compensate for inefficiencies associated with conventional stream based 
protocols. (Walker, Abstract.) The implementation disclosed in Walker 
compensates for limitations that arise when a transaction-based protocol is used 
together with stream-based protocol, the stream-based protocol is modified to take 
advantage of certain characteristics of transaction-based protocols (Walker, Col. 2 
lines 50-55.) 



I-Hi; & HAVES. PI J.C 



10 



While the Walker reference describes modifying the stream-based protocol 
to take advantage of the desirable characteristics of transaction-based protocol, 
Claim 1, in contrast, recites a computer-implemented process comprising: 
determining a size of a data structure; selecting a data streaming protocol when the 
size exceeds a predetermined limit; selecting a buffered data protocol otherwise; 
sending data of the data structure consistent with the selected protocol." 

Walker fails to teach "determining a size of a data structure; selecting a 
data streaming protocol when the size exceeds a predetermined limit', selecting a 
buffered data protocol otherwise; sending data of the data structure consistent 
with the selected protocoF. 

Walker instead describes, with reference to the flow diagram in Fig. 4 
(reproduced below), employing a modified TCP/IP protocol stack at the client 
which utilizes characteristics of the transaction-based protocol to provide more 
efficient network operation. This modified TCP/IP stack is able to reduce system 
delays while increasing network efficiency. 



Initially, after receiving a data packet to be sent to the server, the modified 
TCP/IP protocol stack determines whether a transaction-oriented protocol or a 
Stream-based protocol is being employed in the application layer of the client. If 

a stream-based protocol is determined to be employed in the application layer of 
the client processor, then no further inquiry is necessary and conventional client 
server transactions are continued. If the application layer protocol is determined 
to be transaction-based, a response packet is awaited from the server. Next, the 
header of the server's response to the request is examined to determine the total 
amount of data to be transmitted. Once this information is known, the TCP 
protocol stack sets a state machine to a value related to the amount of data to be 
received. The client keeps track of the segments being received. Through 
comparison of the data remaining with the MTU value for the network, the client 
is able to determine when the amount of data that remains to be received is less 
than an MTU. When the client determines that the amount of data to be transferred 
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from the server is less than the MTU value, the modified TCP implementation 
initiates a preemptive ACK [acknowledgement] signal. In accordance with the 
stream-based protocol, the ACK signal causes the server to send the next segment 
of data stored in the buffer, whether or not it comprises a complete MTU. 
Consequently, the remaining amount of data to be transmitted from the server is 
immediately sent to the client, without the delay normally associated with 
buffering of the data. Walker, Fig. 4, Col 5 lines 10-55. 

The highlighted portion in the description of Fig. 4 of Walker discloses the 
determination of the protocol to be employed (stream-based/transaction-based) is 
made upon the basis of application layer of the client. The subject matter of 
claim 1 on the other hand, recites determining a size of a data structure; selecting a 
data streaming protocol when the size exceeds a predetermined limit; selecting a 
buffered data protocol otherwise. Thus, subject matter of claim 1 selects the 
protocol based on the size of the data structure as opposed to Walker which selects 
the protocol based on the application layer of the client. 

Further, the next highlighted portion discloses that when transaction-based 
protocol is selected, (Walker, Blocks 440-490, Fig. 4) "an ACK signal in 
accordance with the stream-based protocol is still sent out". However, Walker 
discloses that it is a feature of TCP/IP (stream-based) protocol to send an 
acknowledgment signal, ACK, to the server upon successful receipt of a segment. 
(Walker, Col. 4 lines 61-65). Further, Walker also discloses that in contrast to the 
TCP protocol, a transaction-based protocol does not guarantee delivery of data 



segments, and therefore acknowledgments are not employed. (Walker, Col. 5 
lines 5-10). But. the modified stream-based protocol as described by Walker is a 
Transaction-based protocol modified by employing acknowledgement signal, 
which is a characteristic of transaction-based protocol. With this aspect in view, a 
careful analysis of Fig. 4 discloses that the implementation of Walker, based on 
the protocol being applied at the application layer of the client either uses 
conventional stream-based protocol or the modified TCP/IP protocol, which as 
described above is the conventional transaction-based protocol modified to 
generate acknowledgement signal to the client, wherein the acknowledgement 
signal is a feature of TCP/IP or stream based protocol. 

The subject matter of claim 1 on the other hand recites sending data of the 
data structure consistent with the selected protocol. The subject matter of Claim 1 
does not use a modification of protocol as described in Walker, which uses a 
modified stream-based protocol (transaction-protocol employing characteristics 
of stream-based protocol) when transaction-based protocol is selected. Instead 
claim 1 selects and uses a buffered protocol or a streaming protocol for sending 
data, the protocol selection based on the size of the data structure. 

In fact, the Office admits that Walker fails to teach the claimed feature of 
selecting a data streaming protocol when the size exceeds a predetermined limit 
(examiner interpreting data su-eam protocol as bulk data protocol) (Office Action, 
Pg 3, paragraph 4). The examiner therefore turns to Wookey as teaching this 
feature. However, the cited portion in Wookey describes that a short message can 



contain monitoring data, such as events or alarms, a response to a message sent in 

the other direction, bulk data transfer request or response infrastructure control 

message or other data. The cited evidence in Wookey and the preceding 

paragraphs have been reproduced below- 

[0296] The remote services system 100 exchanges information between 
multiple components. The information is classified in two types, a short 
message type and bulk data type . With the short message type, short XML 
messages are used to send information harvested by the remote services 
proxy 210 to the application server 226 to acknowledge receipt of messages 
or to transmit control messages to request bulk transfer. Bulk data type is 
used to transfer data whose size is greater than, e.g.. a few kilobytes, 
between both ends of the remote services system 100 . 

[0297] More specifically, a short message can contain monitoring data, 
such as events or alarms, a response to a message sent in the other 
direction, bulk data transfer request or response infrastructure control 
message or other data. 

The paragraphs above disclose that the remote services system described 
by Wookey exchanges information which is either a short message type or a bulk 
data type. Here, bulk data type is the type of information whose size is greater 
than a stipulated limit. Bulk data type is not a protocol but is a classification of 
information to be exchanged between multiple components of the remote services 
system. Further, the bulk data transfer request is described as an example of the 
monitoring data that can be contained in a short message, but does not disclose 
selecting a data streaming protocol when size exceeds a predetermined limit. 

With respect to protocols, Wookey describes Communication protocols in 



Paragraph [0077]- 



[0077] The communications protocol module 440 provides support of the 
application level protocol that is used for the communication through the 
system. Modules of this type interface to support the use of Email and 
HTTP communications protocols. Tire communication protocol module 440 
interfaces with remote services communications engineering personnel. 

Here, Wookey describes that the communications protocol supports the use 
of email and HTTP protocols. However, Wookey fails to teach or suggest 
determining a size of a data structure; selecting a data streaming protocol when the 
size exceeds a predetermined limit; selecting a buffered data protocol otherwise; 
sending data of the data structure consistent with the selected protocol, as 
described in claim 1 . 

Accordingly, neither Wookey nor Walker teach or suggest any and/or all 
elements of independent claim 1 . Applicant therefore requests reconsideration and 
withdrawal of the rejection. 

Dependent claims 2-10 depend from independent claim 1 and are 
allowable by virtue of this dependency, as well as for additional features that each 
recites. 
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Claims 11-15 



Claim 1 1 recites: 

A computing system for handling messages 
comprising: 

means for processing data from memory; 

means for determining a size of a data structure; 

means for selecting a data streaming protocol when the size exceeds 
a predetermined limit; 

means for selecting a buffered data protocol when the size does not 
exceed the predetermined limit; 

means for sending data of the data structure utilizing the selected 
protocol. 



Walker as discussed above with regard to claim 1 fails to disclose at least 
"determining a size of a data structure; selecting a data streaming protocol when 
the size exceeds a predetermined limit; selecting a buffered data protocol 
otherwise; sending data of the data structure consistent with the selected protocol." 
As mentioned above, Walker describes that determination of the protocol to be 
employed (stream-based/transaction-based) is made upon the basis of application 
layer of the client. Walker, Col 5 lines 17-20. Walker fails to teach selecting a 
data streaming protocol when the size exceeds a predetermined limit; selecting a 
buffered data protocol otherwise. Further, Wookey also fails to disclose selecting 
a data streaming protocol when the size exceeds a predetermined limit. 

Accordingly, neither Wookey nor Walker teach or suggest any and/or all 
elements of independent claim 11. Applicant therefore requests reconsideration 
and withdrawal of the rejection. 



Dependent claims 11-15 depend from independent claim 11 and are 
allowable by virtue of this dependency, as well as for additional features that each 
recites. 

Conclusion 

For at least the foregoing reasons, claims 1-15 are in condition for 
allowance. Applicant respectfully requests reconsideration and withdrawal of the 
rejections and an early notice of allowance. 

If any issue remains unresolved that would prevent allowance of this case, 
Applicant requests that the Examiner contact the undersigned attorney to 
resolve the issue . 

Respectfully submitted, 

Date: July 22. 2008 By : ../Christopher W. Lattin/ 

Christopher W. Lattin 
Lee & Hayes, pile 
Reg. No. 51,275 

(509) 324-9256 ext. 263 



